98장. CF → APIGW → ALB → ECS → RDS/DynamoDB 통합 흐름

이 장에서 말하고자 하는 것

이 책의 척추 그림을 책 처음부터 반복해 왔다.

사용자 → DNS → CloudFront → API Gateway → ALB → ECS → DB

이 장은 그 흐름을 한 요청의 일대기 로 따라가며
그동안 배운 모든 부품이 어떻게 한 줄에 늘어서는지 정리한다.

1. 한 요청이 통과하는 12 단계

사용자가 POST https://example.com/api/orders 를 호출한다.

 1. DNS 질의             → Route 53 ALIAS → CloudFront
 2. TLS 핸드셰이크       → CloudFront (us-east-1 ACM)
 3. WAF 검사             → 통과
 4. CloudFront 캐시 확인  → /api/* 는 캐시 비활성 → origin으로
 5. API Gateway 도달      → JWT Authorizer 검증 → ALLOW
 6. Rate limit 통과
 7. VPC Link → Private ALB
 8. ALB 규칙 매칭         → /api/orders/* → TG-orders
 9. ALB → ECS Task        → 보안 그룹 통과
10. 컨테이너 처리          → DB · 캐시 · 이벤트 발행
11. 응답 반환             → ALB → APIGW → CloudFront → 사용자
12. 부수 효과 (비동기)     → SNS → SQS → 워커들

이 12 단계의 부품들이 1~96장의 거의 모든 챕터에 대응한다.

2. 각 단계의 책임 다시 보기

각 단계가 자기 영역에서만 일한다.

3. 같은 흐름을 IaC로

이 12 단계 전체가 Terraform 으로 표현된다.

module "network"   { source = "./modules/vpc" ... }
module "edge"      { source = "./modules/cloudfront" ... }
module "api_entry" { source = "./modules/apigw" ... }
module "shared"    { source = "./modules/alb" ... }

module "users"     { source = "./modules/microservice"  name = "users" ... }
module "orders"    { source = "./modules/microservice"  name = "orders" ... }
module "payments"  { source = "./modules/microservice"  name = "payments" ... }

module "events"    { source = "./modules/event-bus"  ... }
module "workers" {
  source   = "./modules/worker-fleet"
  services = ["notification", "analytics", "inventory"]
}

module "observability" { source = "./modules/observability" ... }
module "backup"        { source = "./modules/backup" ... }

• 모든 자원은 코드로
• 환경(dev / stage / prod) 은 변수만 다르게

4. 보안 깊이 — 한 요청에 닿는 보안 계층

CloudFront WAF → API Gateway 인증 → VPC Link → Private ALB SG → Task SG → DB SG
       ↓             ↓                  ↓             ↓             ↓        ↓
   엣지 그물     첫 인증 필터        사설 경로       LB→Task     Task→DB   DB만 받음

이 모든 단계 + IAM · KMS · Secrets Manager 가 “Defense in Depth” 를 만든다.

한 계층이 뚫려도 다른 계층이 막는다

5. 관측성 — 한 요청을 시간별로 따라가기

사용자                    trace_id 발급
  ↓
CloudFront 로그            trace_id 함께 기록
  ↓
API Gateway 로그           trace_id, JWT의 user_id
  ↓
ALB 액세스 로그            trace_id (헤더로 전달)
  ↓
ECS 컨테이너 stdout         JSON 로그, trace_id, user_id, request_id
  ↓
X-Ray Segment              ECS · DB · 외부 호출 시간 분포
  ↓
CloudWatch Metric          5xx, p95, p99

trace_id 하나만 있으면 어느 시점에 어디서 무엇이 일어났는지 끝까지 추적 가능

6. 비용 — 한 요청에 따라붙는 청구서

요청 하나의 비용은 다음 항목의 작은 조각이 모인 합이다.

• CloudFront 요청 수 + 데이터 전송
• WAF 요청 평가
• API Gateway 요청 수
• ALB 처리 단위 (LCU)
• ECS Fargate vCPU · 메모리 시간
• RDS 시간 + I/O
• DynamoDB 요청 단위
• CloudWatch 로그 GB
• X-Ray 트레이스 수
• 데이터 송신 (CloudFront 외부, NAT, VPC Endpoint)

한 요청이 한 자릿수 원도 안 된다. 하지만 모이면 운영 비용의 95%

7. 장애가 났을 때 — 흐름을 거꾸로 추적

사용자: "주문이 안 돼요"
  ↓
CloudWatch Dashboard → ALB 5xx 가 늘었나?
  ↓ Yes
ALB → 어느 TG?
  ↓ TG-orders
ECS Service "orders" → 어떤 Task?
  ↓
CloudWatch Logs Insights → 5xx 응답의 trace_id 추출
  ↓
X-Ray → 그 trace의 어디서 지연/에러?
  ↓
RDS slow query? → CloudWatch RDS Performance Insights

문제가 어디서 났는지 분 단위로 좁힌다.

8. 우리 서비스의 한 요청 (실제 예)

POST https://example.com/api/orders
Authorization: Bearer <JWT>
{
  "items": [...],
  "user_id": "u-1"
}

→ Route 53 ALIAS → CloudFront (cache miss) → APIGW (JWT OK)
→ ALB /api/orders/* → ECS orders Task
  → users.local (Cloud Map) → user 정보 조회
  → orders-db INSERT
  → SNS "OrderCreated"
→ HTTP 201 응답

비동기:
  notification 워커: SQS → 이메일 발송
  analytics 워커:    SQS → DynamoDB 기록
  inventory 워커:    SQS → 재고 차감

이 한 줄 안에 1~96장의 거의 모든 개념이 들어 있다.

9. 직접 따라 만들어보기 — 권장 순서

처음 만든다면 이 순서가 가장 무리 없다.

1. VPC + 서브넷 (19~28장)
2. ALB + 도메인 + ACM (30~37장)
3. ECR + 도커 이미지 + ECS 1개 서비스 (41~51장)
4. CloudFront 끼우기 (38~40장)
5. API Gateway 끼우기 (52~54장)
6. RDS 붙이기 (62~63장)
7. ElastiCache · DynamoDB 필요할 때 (66~69장)
8. SQS · SNS 로 비동기 분리 (74~76장)
9. 관측성 · 백업 · CI/CD (83~96장)
10. 두 번째 · 세 번째 서비스로 확장 (97장)

한 번에 다 깔지 않는다 — 한 층씩 올리면서 동작을 확인

10. 코드로는 이렇게 생겼다 — 한 줄 호출의 IaC 흔적

api.example.com → orders 서비스 한 줄을 만드는 데
관여하는 Terraform 리소스가 (대략):

aws_route53_record         (api.example.com → CloudFront)
aws_acm_certificate         (us-east-1, 서울)
aws_cloudfront_distribution
aws_wafv2_web_acl
aws_apigatewayv2_api / authorizer / vpc_link / integration / route
aws_lb / listener / target_group / listener_rule
aws_security_group (alb, task, db)
aws_ecs_cluster / task_definition / service
aws_iam_role (task_execution, task_role)
aws_db_instance (orders-db)
aws_secretsmanager_secret
aws_cloudwatch_log_group / metric_alarm

작아 보이는 흐름 뒤에 이만큼이 받친다.

11. 이렇게 쓰면 망한다 — 통합 단계의 흔한 함정

함정 1. 한 번에 다 만들고 한 번에 동작시킨다

어디가 실패했는지 모른다.

한 층씩 올린다 — 그때마다 curl로 확인

함정 2. dev에서만 동작 확인

prod는 IAM · 네트워크 · KMS 가 더 좁다. 환경별 검증 필요.

함정 3. trace_id 를 안 흘린다

12 단계 어디에서 끊겼는지 추적이 안 된다.

함정 4. 알람 없이 운영

사용자가 알려야 알게 된다. 사용자 신뢰가 가장 비싼 비용.

12. 한 줄로 정리

한 요청은 12 단계를 통과하며, 각 단계는 자기 책임만 진다.
그 모든 단계가 trace_id 하나로 묶여 추적 가능할 때 운영이 가능하다.

13. 이 장의 핵심 정리

1. CF → APIGW → ALB → ECS → DB 의 12 단계가 한 요청의 일대기다.
2. 각 단계는 책임이 겹치지 않는다.
3. Defense in Depth 가 보안 깊이를 만든다.
4. trace_id 하나로 모든 단계가 묶여 추적 가능하다.
5. 운영 비용의 대부분은 작은 항목들의 누적이다.
6. 한 번에 만들지 않는다 — 한 층씩 올리면서 확인한다.